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1.  INTRODUCTION 

This  Quarterly  Technical  Report  No.  3  describes  several 
aspects  of  our  progress  on  the  ARPA  computer  network  during 
the  third  quarter  of  1969.  During  this  period,  the  first 
IMP  was  delivered  to  UCLA  on  schedule  with  an  operational 
program.  The  IMP  successfully  communicated  with  the  UCLA 
Host  computer  (a  Sigma  7). 

In  Section  2,  we  describe  the  test  programs  developed, 
the  testing  procedure  used,  and  the  technical  problems 
encountered  In  installing  the  initial  IMP.  In  Section  3, 
we  outline  several  new  features  that  have  been  Incorporated 
into  the  operational  IMP  program. described  in  our  Quarterly 
Technical  Report  No.  2  (BBN  Report  No.  1837).  We  will  soon 
make  these  features  available  in  a  second  version  of  the 
operational  program.  We  have  begun  a  preliminary  study  of  the 
IMP  program  In  an  attempt  to  understand  its  performance.  A 
few  projected  measure.*?  of  program  performance  are  presented  In 
Section 

Documentation  during  this  quarter  consisted  of  two  minor 
revisions  of  the  Host  specification  (BBN  Report  No.  1822). 
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2.  HARDWARt  CHECKOUT  AND  INSTALLATION 

During  this  quarter,  we  tested  the  IMPs  Intensively.  After 
being  tested  separately,  the  IMPs  were  combined  Into  small  net¬ 
works  of  two  or  three  locally  connected  IMPs  and  then  retested. 
Upon  Installation  at  UCLA,  the  IMP  was  tested  further. 

A.  Test  Program  Development 

An  extensive  program  has  been  developed  for  checkout  and 
testing  of  the  IMP.  The  program  consists  of  two  parts;  first, 
a  section  that  performs  one-time  tests  on  several  special  IMP 
features  (watchdog  timer,  automatic  restart,  memory  protection, 
power-fall  interrupt,  etc.);  and  second,  a  loop  that  repeatedly 
drives  a  selectable  data  pattern  through  the  Interfaces  to  com¬ 
pare  Incoming  data  with  outgoing  data  for  errors .  The  data  can 
be  driven  through  a  crosspatched  Interface,  through  a  locally 
looped  modem,  through  a  phone  line  looped  at  a  remote  location, 
or  to  another  IMP  performing  an  Identical  test. 

The  tests  have  uncovered  bad  cables  and  logic  packs,  a 
number  of  wiring  deficiencies,  two  minor  Interace  design  errors, 
and  a  design  problem  In  the  DDP-516  data-channel  hardware.  We 
are  preparing  a  manual  that  describes  verification,  test,  and 
Installation  procedures  and  discusses  the  test  progrri.i  In  detail. 

B.  Test  Cell  Activity 

During  this  quarter,  Honeywell  delivered  IMPs  Number  2  and 

3.  As  with  IMP  No.  1,  these  machines  contained  a  considerable 
number  of  faults  which  were  debugged  and  corrected  In  the  Test 
Cell. 

A  small  temporary  hardware  patch  to  the  Modem  interfaces 
in  IMPs  1  and  2  made  possible  the  direct  connection  of  these 
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Interfaces ,  thereby  removing  the  need  for  Intervening  modems . 
This  modification  allowed  for  the  construction  of  a  three  node 
pseudo-network  as  shown  In  Figure  1  below: 


TEST  CELL  MODEMS 


^  HOST  interfaces 
VTA  MODEM  INTERFACES 


riG.  1 


This  configuration  provides  a  reasonably  sophisticated 
setting  for  hardware  testing  and  also  allows  for  debugging  of 
configuration  dependent  features  (e.g.,  routing)  of  the 
operational  program.  An  equivalent  configuration  was  constructed 
using  IMP  No.  3  to  replace  IMP  No.  1  after  the  latter  had  been 
shipped  to  UCLA. 
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C.  Initial  Installation  Activity 

within  a  few  days  of  its  delivery  to  UCLA  on  Saturday, 
August  30,  the  IMP  was  connected  to  and  operating  with  both 
the  Sigma  7  and  the  phone  company  equipment.  Intensive  test¬ 
ing  revealed  a  minor  design  error  in  the  IMF's  standard  Host 
interface  and  a  minor  design  error  and  some  bad  components  in 
the  Host’s  special  Interface.  After  these  errors  were  cor¬ 
rected,  tests  were  conducted  with  the  UCLA-SRI  ohone  line 
looped  at  the  SRI  end,  and  messages  were  successfully  sent 
around  this  loop.  During  installation,  we  decided  that  we 
would  like  to  test  the  nhone  company  equipment  but  we  found 
that  the  program  used  in  the  BBN  Test  Cell  was  not  appropriate 
for  studying  phone-line  error  characteristics.  We  are  pre¬ 
sently  writing  a  program  for  this  purpose. 

At  the  time  of  installation,  we  recognized  a  need  for  the 
Sigma  7  Host  to  have  its  own  test  program  for  communication 
with  its  IMP,  A  cooperative  UCLA-BBN  effort  resulted  in  a 
simple  program  to  send  and  receive  character  strings  between 
the  IMP  and  Host  teletypes.  This  approach  proved  so  success¬ 
ful  that  we  plan  to  encourage  the  use  of  sim.llar  programs  in 
all  future  installations. 

We  found  the  phone  company  installations  at  UCLA  and  SRI 
to  be  inconsistent  with  regard  to  physical  configurations  of 
voice  circuits  cabinetry,  original  design,  etc.  These  dif¬ 
ficulties  were  reported  to  the  telephone  company. 
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3.  SOFTWARE  DEVELOPMENT 

The  software  effort  during  this  quarter  was  devoted  to 
Implementing  the  program  design  described  In  our  Quarterly 
Technical  Report  No.  2.  Version  1  of  the  operational  pro¬ 
gram  was  delivered  to  UCLA  with  the  first  IMP.  At  this  time. 
Implementation  Is  almost  complete. 

During  this  Implementation  period,  new  software  features 
involving  error-recovery  procedures  have  been  added  to  the 
program.  These  procedures  handle  the  failure  of  an  IMP  or  a 
Hose,  with  consequent  loss  of  whole  or  partial  messages  from 
the  network.  We  feel  that  after  a  reasonable  period,  on  the 
order  of  many  minutes,  all  trace  of  such  an  event  should  be 
eliminated  from  the  network  and  that  the  user  should  be  In¬ 
formed  of  the  occurrence. 

Error-recovery  procedures  fall  Into  two  categories :  the 
response  of  the  network  to  an  IMP  or  a  Host  failure  and  the 
response  of  an  IMP  to  its  own  failure. 

A.  Network  Failure  Recovery 

An  IMP  may  detect  a  network  failure  In  one  of  three  ways: 

1,  A  packet  expected  for  reassembly  of  a  multiple 
packet  message  never  arrives . 

2.  A  link  in  the  link  table  of  the  transmit  IMP  Is 
never  unblocked. 

3-  The  Host  does  not  take  a  message  from  Its  IMP. 

If  a  message  Is  not  fully  reassembled  in  15  minutes,  the 
system  presumes  a  failure.  The  message  is  discarded  and  a 
RPNM  returned  with  a  "transmission  Incomplete"  bit  set.  This 
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■RPNM,  In  turn.  Is  passed  along  to  the  transmitting  Host  as 
Error  Message  Number  9. 

If  the  Host  has  not  taken  a  message  after  15  minutes,  the 
system  presumes  that  It  will  never  take  the  message.  Therefore, 
as  In  the  previous  case,  the  message  Is  discarded  and  a  RFNM 
with  the  Incomplete  transmission  bit  Is  returned  to  the  source 
Host. 

If  a  link  remains  blocked  for  longer  than  20  minutes,  the 
system  again  presumes  a  failure,  perhaps  a  lost  RFNM  or  a  lost 
message.  The  link  Is  unblocked  and  an  Incomplete  transmission 
error  message  Is  sent  to  the  source  Host.  The  delay  is  slightly 
longer  for  this  failure  so  that  the  other  failure  mechanisms 
will  have  a  chance  to  operate  and  unblock  the  link. 

All  three  failures  involve  an  event  that  takes  much  longer 
that  it  should.  For  the  present,  we  have  tried  to  pick  reason¬ 
able  time  limits  for  each  case;  as  we  discover  more  about  the 
behavior  of  the  network,  we  will  be  able  to  define  these  limits 
more  exactly. 

In  all  three  cases.  Error  Message  No.  9  Is  given  to  the 
transmitting  Host.  We  expect  that  failures  of  this  sort  will 
be  infrequent  enough  to  permit  the  human  operator  controlling 
the  Host  transmission  to  determine  how  to  proceed. 

B.  IMP  Failure  Recovery 

An  IMP  can  recover  from  Its  own  failure  in  two  ways.  In 
the  event  of  power  failure,  a  hardware  feature  permits  the  IMP 
to  turn  off  the  program  before  the  program  destroys  Itself. 

When  power  returns,  the  IMP  restarts  automatically.  We  con¬ 
sidered  several  possibilities  for  handling  the  packets  found 
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in  an  IMP  during  a  power  failure  amd  concluded  that  no  plan  to 
salvage  the  packets  was  both  practical  and  foolproof.  For 
example j  we  cannot  know  whether  the  packet  In  transmission  at 
the  time  of  failure  successfully  left  the  machine  before  the 
power  failed.  Should  that  packet  be  reintroduced  Into  the 
network  after  a  lengthy  delay.  It  might  actually  be  delivered 
twice!  Therefore,  we  decided  simply  to  discard  all  the  packets 
and  restart  the  IMP  program. 

The  second  recovery  mechanism  Is  the  "watchdog  timer", 
which  transfers  control  to  protected  memory  whenever  the  pro¬ 
gram  neglects  this  timer  for  about  one  minute.  Everything 
unique  to  a  particular  IMP  must  reside  in  Its  protected  memory. 
Only  one  register  (containing  the  IMP  number)  currently  differs 
from  IMP  to  IMP. 

We  presume  that  the  program  In  unprotected  memory  Is 
destroyed  either  through  a  hardware  transient  or  software  fail¬ 
ure.  The  program  In  protected  memory  sends  a  reload  request 
dcwn  a  phone  line  selected  at  random.  The  neighboring  IMP  re¬ 
sponds  by  sending  a  copy  of  Its  whole  program  back  on  that  phone 
line.  A  normal  IMP  would  discard  this  message  because  It  Is  too 
long,  but  the  IMP  In  trouble  can  reload  Its  program.  The  pro¬ 
cess  of  reloading  from  the  network  takes  only  a  few  seconds  and 
can  be  repeated  until  successful.  This  feature  of  loading  from 
the  network  would  permit  delivery  and  Incorporation  of  a  new 
version  of  software  through  the  network.  However,  we  still  view 
paper  tape  as  the  primary  input  medium. 

C.  Stopping  an  IMP 

Care  must  be  taken  to  stop  a  working  IMP  without  Introducing 
network  failures.  Therefore,  we  have  implemented  a  "clean  stop" 
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feature  (a  special  switch)  that  shuts  down  the  IMP  without  los¬ 
ing  messages.  The  program  Initiates  the  following  sequence  of 
events  when  the  IMP  Is  taken  down  cleanly: 

1.  Sends  the  Host  an  "IMP  going  down"  message. 

2.  Walts  5  seconds  to  let  the  Host  finish  network 
transactions . 

3.  Refuses  messages  from  the  Host  and  notifies  the 
network  that  the  Host  Is  dead. 

Walts  5  seconds  to  let  other  Hosts  learn  that 
this  Host  Is  dead. 

5.  Refuses  messages  from  the  network. 

6.  Walts  5  seconds  to  allow  Its  IMP  to  empty  of 
store  and  forward  messages. 

7.  Stops. 


8 


Report  No.  1890 


Bolt  Beranek  and  Newman  Inc. 


I 

i 

n 

D 

D 

0 

D 


4.  PROJECTED  IMP  PERFORMANCE 

During  the  last  quarter  we  began  to  study  the  projected 
performance  of  the  IMP.  This  study  was  based  upon  a  recent 
version  of  the  operational  program  and  provides  only  pre¬ 
liminary  data.  The  IMP  has  not  yet  been  tested  under  heavy 
load  conditions  and  consequently  no  experimental  data  is 
available.  In  the  following  paragraphs,  we  present  a  few 
conclusions  about  IMP  performance. 

A.  Capacity  In  Connected  Lines 

The  amount  of  traffic  flowing  on  a  fifty  kilobit  line 
fully  loaded  with  store  and  forward  packets  Is  adopted  as  a 
unit  traffic  load  on  the  IMP.  We  call  this  unit  an  sf festive 
channel.  Thus,  a  fifty  kilobit  line  offers  at  most  one  ef¬ 
fective-channel  load,  while  a  230.4  kilobit  line  offers  at 
moot  a  load  of  4.6  effective  channels.  Conveniently,  the 
processing  time  for  a  message  on  the  Host  line  Is  about  equal 
to  the  processing  time  for  the  same  message  on  a  phone  line; 
thus.  Host  lines  and  phone  lines  are  equal  with  regard  to 
effective-channel  traffic. 

The  computational  capacity  of  the  IMP  is  a  function  of 
message  length.  For  a  load  consisting  only  of  short  messages 
(one  word),  the  capacity  is  seven  effective  channels.  For  the 
longest  messages  (eight  packets),  the  capacity  Is  nineteen 
effective  channels . 

B.  IMP  Throughput 

We  adopt  the  IMP  throughput  In  bits/second  as  a  measure 
of  IMP  perfonnance .  The  throughput  Is  the  maximum  number  of 
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Host  data  bits  that  may  traverse  an  IMP  each  second.  The 
actual  number  of  bits  entering  the  IMP  each  second  is  some¬ 
what  larger  than  the  througput  because  of  such  message 
overhead  as  headers,  RPNMs  and  acknowledgements.  Each  packet 
on  the  phone  lines  contains  seventeen  characters  of  overhead, 
thirteen  of  which  are  removed  before  the  packet  enters  an 
IMP. 

The  maximum  IMP  throughput  of  approximately  700,000 
bits/second  is  achieved  with  large  (8  packet)  messages  on 
nineteen  effective  channels.  A  curve  of  maximum  throughput 
as  a  function  of  message  length  is  shown  in  Figure  2.  The 
difference  between  the  throughput  curve  and  the  line  traffic 
curve  represents  overhead. 
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l».  AOSTRACT 


The  basic  function  of  the  IMP  computer  network  is  to  allow  large 
existing  time-shared  (Host)  computers  with  different  system  configura¬ 
tions  to  communicate  with  each  other.  Each  IMP  (Interface  Message  Pro¬ 
cessor)  computer  accepts  messages  for  its  Host  from  other  Host  computers 
and  transmits  messages  from  its  Host  to  other  Hosts.  Since  there  will 
not  always  be  a  direct  link  between  two  Hosts  that  wish  to  communicate, 
individual  IMPs  will,  from  time  to  time,  perform  the  function  of  trans¬ 
ferring  a  message  between  Hosts  that  are  not  directly  connected.  This 
then  leads  to  the  two  basic  IMP  configurations  —  interfacing  between 
Host  computers  and  acting  as  a  message  switcher  in  the  IMP  network. 

The  message  switching  is  perfonned  as  a  store  and  forward  operation. 

Each  IMP  adapts  its  message  routine  to  the  condition  of  those  portions 
of  the  IMP  network  to  which  it  ij  ;onnected.  IMPs  regularly  measure 
network  performance  and  report  1,  special  messages  to  the  network  meas¬ 
urement  center.  Provision  of  a  tracing  capability  permits  the  net 
operation  to  be  studied  comprehensively.  An  automatic  trouble  reporting 
capability  detects  a  variety  of  network  difficulties  and  reports  them 
to  an  interested  Host.  An  IMP  can  throw  away  packets  that  it  has  re¬ 
ceived  but  not  yet  acknowledged,  transmitting  packets  to  other  IMPs  at 
its  K  -’r-  discretion.  Self-contained  network  operation  is  designed  to 
portect  and  deliver  messages  from  the  source  Host  to  the  destination 
Host. 
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